Lookerベスト・プラクティス：LookML開発ガイドライン(サンプル) #looker

Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『LookML開発におけるガイドラインのサンプル』についてご紹介したいと思います。

• Example LookML Development Guidelines - LookML / Modeling - Looker Community

この内容はベスト・プラクティスとして紹介されていた内容から派生する形となりますが、Lookerの開発をLookMLで行って行く上で定めておいた方が良い『ガイドライン』について言及されているものであり、実際に導入を行うプロジェクトとしても『あった方が良い』類のものであると思い、採り上げてみた次第です。

目次

• 1.各ビュー(view)の上部に名前、作成日、目的を追加
• 2.ファイル形式を考慮したタイトル付け
• 3.新しいフィールドごとに名前、作成日、説明を追加
• 4.一回限りのフラグを立ててフィールドをテストする
• 5.1回限りのビューファイルで1回限りの探索を行う場合、それらは整理し非表示としておく
• 6.コミット前に全てのLookMLの警告とエラーを解決しておく
• 7.拡張済みのオブジェクトを更に拡張させない
• 8.ビュー(view)やエクスプローラ(Explore)、モデル(model)の"所有者"をはっきりさせる
• 9.コードのバージョン管理ルール
• 10.PDT(派生テーブル)作成時の取り決め
• まとめ

　

1.各ビュー(view)の上部に名前、作成日、目的を追加

特定のファイルを解析する際は、その意図などを元作成者に聞き行けるに越した事はありません。新しいビューファイルを作成する際は、以下のスクリーンショットに示すように、ビューファイルの上部に名前、作成日、目的を書き入れておきます。

　

2.ファイル形式を考慮したタイトル付け

ファイル形式がsub-organization.view_title.view.lkmlとなるように、ビュー(view)にはsub-organization.viewというタイトルを付けます。

これにより、サブ組織の全てのビューファイルに、include: sub-organization.*.view.lkmlという形でワイルドカード(*))を使用出来ます。以下使用例です。

• marketing.campaigns.view.lkml - マーケティングモデルに使用されます
• salesforce.leads.view.lkml - セールスモデル、より具体的にはsalesforceモデルに使用されます
• dcl.chat_reviews - 品質管理のサポートモデルによって使用されます

　

3.新しいフィールドごとに名前、作成日、説明を追加

LookMLフィールドそれぞれにとっては、そのフィールドのタイトルやラベルがどれほど単純であっても説明が必要です。以下のように、フィールド定義に名前、日付、及びフィールドの機能説明文を追記してください。

単一フィールドの場合：

フィールドセットの場合：

　

4.一回限りのフラグを立ててフィールドをテストする

group_label : "Test"を使い、全ての一時フィールドに_testを追加します。

全てのPDT(一時派生テーブル)に、プレフィックス:oo_を追加します。

　

5.1回限りのビューファイルで1回限りの探索を行う場合、それらは整理し非表示としておく

1回限りのエクスプローラ(Explore)は、その所有者が作成した1回限りのビュー(view)ファイル内に留めておくべきです。そういったものを作成する場合は、他ユーザーからそれを見えないようにし、本番環境にコミットする際にはラベルでその意図や内容を示しておきましょう。これを行う場合、hiddenパラメータが利用出来ます。

• hidden (for Explores)

　

6.コミット前に全てのLookMLの警告とエラーを解決しておく

ALL errors and warningsが解決されたことを確認せずに、コードをコミットしてはいけません。 頻繁に検証とテストを行うことで、エラーの原因を簡単に絞り込むことが出来、何百ものエラーに圧倒されることが無くなります。

　

7.拡張済みのオブジェクトを更に拡張させない

既に拡張がされているエクスプローラ(Explore)を拡張すると、デバッグの際に混乱を招く可能性があります。モデル(Model)を『エッシャーの迷路』にしないでください。

• エッシャー 迷路 - Google 検索

　

8.ビュー(view)やエクスプローラ(Explore)、モデル(model)の"所有者"をはっきりさせる

これら要素のサイズと複雑さに応じて、"所有者"を指定します。問い合わせ等が発生し得る場合はそれら指定を行うだけでは無く、ファイルの検証や保守も担当を置くことを検討してください。

　

9.コードのバージョン管理ルール

新しいコードをコミットする際は、そのフィールドの元の作成者(または所有者)にタグを付け、Pull Requestで表示または探索します。変更を所有者に通知することで、指摘箇所を明確にしたり、提案を行ったり、コードレビューの実施がスムーズになります。

　

10.PDT(派生テーブル)作成時の取り決め

PDT(派生テーブル)を構築する必要がある場合、PDTへのデータグループへの作成または追加について、リード開発者と相談してください。データグループの作成に関する理由、または特定のデータグループを選択した理由についてプルリクエストで簡単に説明するようにしてください。

　

まとめ

というわけで、Lookerにおける『LookML開発におけるガイドラインのサンプル』のご紹介でした。

LookerはGitリポジトリと連携させることが容易に行えるのでそこまで心配することは無いのかもしれないですが、それでも関わる人数が増えてくる、扱うリソースが増えてくるといった状況になってくるとこういった『ガイドライン』の存在が効果的に効いてくるはずです。プロジェクト初期の時点からこの様なガイドラインを策定、導入していって『会社・プロジェクト独自の"必勝"開発ガイドライン』を作り上げて行けると良いですね。

• Lookerベスト・プラクティス ｜ シリーズ ｜ DevelopersIO